The present invention relates to storage area networks (SANs). In particular, the present invention relates to an offload processor in a storage server.
FIG. 1 is a block diagram of a storage area network (SAN) system 10. The SAN system 10 includes a host 12, a network 14, a storage server 16, and a storage system 18. The host 12 generally includes a computer that may be further connected to other computers via the network 14 or via other connections. The network 14 may be any type of computer network, such as a TCP/IP network, an Ethernet network, a token ring network, an asynchronous transfer mode (ATM) network, a Fibre Channel network, etc. The storage system 18 may be any type of storage system, such as a disk, disk array, RAID (redundant array of inexpensive disks) system, etc.
The storage server 16 generally transparently connects the host 12 to the storage system 18. More specifically, the host 12 need only be aware of the storage server 16, and the storage server 16 takes responsibility for interfacing the host 12 with the storage system 18. Thus, the host 12 need not be aware of the specific configuration of the storage system 18. Such an arrangement allows many of the storage management and configuration functions to be offloaded from the host.
Such offloading allows economies of scale in storage management. For example, when the storage system 10 has multiple hosts on the network 14 and the components of the storage system 18 are changed, all the hosts need not be informed of the change. The change may be provided only to the storage server 16.
Similar concepts may be applied to other storage system architectures and arrangements such as networked attached storage (NAS), etc.
It is advantageous for the storage server 16 to quickly perform its SAN network processing functions. Such functions include semaphore management, out-of-order frame processing, and timer management.
Semaphore management involves managing semaphores that control access to data space. For example, if one process thread is accessing a particular data space of the storage system 18, then no other process threads should access that data space until the first process thread has completed its access. Otherwise the second process thread could alter the data in the data space in a detrimental manner. Semaphore management is typically performed in software.
Out-of-order frame processing involves re-arranging frames received out of order by the storage server 16. For example, if the storage server 16 is accessing data that is stored on more than one disk 18, the data from one disk 18 may arrive before the data from another disk 18. The host 12 expects the data in a particular order, so the storage server 16 typically re-orders the data before it is forwarded on to the host 12. Frame re-ordering is typically performed in software.
Timer management involves creating, checking, and stopping timers related to various activities that the storage server 16 performs. For example, the storage server 16 sets a timer when accessing an element of the storage system 18. If the element fails to respond, the timer expires, triggering action by the storage server 16 to re-access the element, to perform diagnostic processing, or to otherwise respond to the failure. Timer management is typically performed in software.
Typical implementations of the above three functions may be inefficient. The software implementing each function typically occupies the general code space in the storage server 16. Such code space is a limited resource that it is often advantageous to conserve. The execution of such software requires processor overhead.
Aspects of the present invention are directed toward improving the operation of these three functions in the storage server 16.